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HARDWARE AND SOFTWARE REQUIREMENTS FOR THE 
PROPULSION FLIGHT ANALYSIS COMPUTERS 
By Joe M. Thames, Jr. 

INTRODUCTION 


The purpose of this document is to identify the hardware and soft- 
ware requirements of the propulsion flight analysis computers and to 
discuss them in more detail than the treatment given in reference 1. 

This is not meant to be a detailed equipment specification. Therefore, 
specific reference to equipment types must be regarded as conceptual 
guidelines only. 

Reference 1 presents an overall plan for the flight evaluation of 
the Apollo propulsion systems. Emphasis is placed on inflight evaluation 
(postfiring analysis). The means for such analysis is to be provided by 
a special purpose data processing system, the "Flight Analysis Computer." 
Figure 1 illustrates the application of such hardware in the overall mis- 
sion analysis network. 

The computer arrangement, presented in reference 1, is given in 
figure 2. It consists of a large "main- frame" computer, the "propulsion 
flight analysis computer," and a smaller satellite -computer, the "propul- 
sion analysis control computer." 

The functions of the computer system are: 

a. To perform the essential calculations required for flight-time 
propulsion analysis, utilizing real-time firing data; 

b. To present the results in a manner which facilitates under- 
standing and interpretation; and 

c. To perform the necessary calculations to predict ensuing mission 
consequences. 
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OPERATION OF THE FLIGHT ANALYSIS COMPUTER 


The computer system will he required to operate in three different 
modes, each fulfilling a particular purpose: 

a. Job-shop operation mode, 

b. Inflight analysis mode, and 

c. Analysis simulation mode. 

It is important that facilities be provided which permit peripheral 
hardware segregation for each mode. This could be most easily accom- 
plished using a time-sharing, multiprocessing computer system. However, 
realistic delivery dates for such hardware would not permit their utili- 
zation for the early manned Apollo missions. Simultaneous processing 
with the main frame computer is therefore excluded for the present. 

Without time sharing, an interrupt -re store capability ir required 
for continuous processing. When operating in the job-shop mode, the main 
frame could be interrupted by the satellite for inflight analysis or 
analysis simulation processing. Control would be immediately returned 
to the job -shop mode upon completion of the flight analysis jobs. 
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Job -Shop Operation 

Normal data processing operation could be accomplished in an. off- 
line manner in which jobs would be batch processed by the main frame. 
When interrupted, control would be temporarily transferred to the flight 
analysis mode (inflight analysis or analysis simulation). Upon comple- 
tion of the flight analysis job, control would be restored to the job- 
shop program to enable it to continue execution from the point of 
interruption. The only loss to the original job would be turn-around 
time. 


Inflight Analysis Operation 

Ltimediately following the firing of the propulsion system, teleme- 
tered data would be evaluated by the flight analysis programs. The 
primary progrem, REALBFPP, is to be contained in auxiliary storage, with 
its associated empirical model data, ready to be loaded into the main 
frame for execution (see fig. 2). The flight data (reduced real-time 
data) necessary for the execution are received directly from an outside 
source (the data reduction computer). Actually, such data could be 
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accumulated In auxiliary storage and verified by the satellite computer, 
prior to interruption of the main frame. When sufficient data (for a 
particular engine firing) have been received and verified, the main frame 
would be interrupted. REALBEPP would be loaded from auxiliary storage 
and would begin processing the flight data. The interruption would be 
triggered by the satellite operator through activation of a special in- 
struction. All output of the main frame would be transmitted directly 
to the satellite (core-to-core) or to auxiliary storage common to both 
machines. All peripheral processing would subsequently be conducted by 
the satellite computer. Upon completion of the REALBEPP execution, the 
original (job -shop) program would be restored to execution automatically, 
The satellite would continue processing independent of the main frame. 

Subsequent operation of the satellite would be concerned with the 
interpretation of the REALBEPP output. Certain plots and displays would 
be generated to aid in the interpretation. A means for quick-load-and-go 
programing would be available for on-the-spot programs to aid in the in- 
terpretation (for example: calculation of the mean and standard devi- 

ation of a data set). 

Following output interpretation, the resulting information would be 
transmitted to the Flight Control personnel. Tnis would be accomplished 
through various types of visual aids such as plots, text prints, et cet- 
era. 


To predict mission consequences of the evaluated firing and to ex- 
trapolate mission performance, new trajectories would be projected based 
on the interpreted firing results. This could be accomplished as part 
of the REALBEPP analysis. It is mere likely, however, that this would 
be accomplished by another program in a different computer, namely the 
RTCC Real Time Trajectory Simulator. If so, an additional satellite 
function would involve transmission of information to the RTCC. 


Analysis Simulation 

In any complex flight system, much attention is usually directed 
toward the detection and resolution of malfunctions. Indeed, most of 
the flight instrumentation is strategically placed for this purpose. 
Often, however, malfunctioning instruments tend to add to the mystery 
rather than aid in its resolution. 

The flight analysis method (BEPP), by sampling and comparing trajec- 
tory data and propulsion data with reference to applicable physical laws, 
offers a universal diagnostic capability, i'll that is lacking is prior 
knowledge of how the particular malfunctions manifest themselves in the 
output of the BEPP programs (malfunction signatures). 
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The malfunction signatures can be estab3,ished by analysis simula- 
tion. Malfunctions would be simulated by the Propulsion Mission Simu- 
lator Program PREBEPP. The results of PREBEPP would be used to input 
the inflight analysis program REALBEPP. The results of REALBEPP would 
provide the required signatures. 

Computer operation will be similar to the actual flight time opera« 
tion of the inflight program. However, PREBEPP results will be substi- 
tuted for telemetered data. Simulation would not involve the Mission 
Control Center in all cases. It is therefore desirable that facilities 
be provided for performing simulations in the Propulsion Building as 
well. 


CONCEPTUAL HARDWARE CONFIGURATIONS 


Configuration 1 

The logical expansion of the figure 2 hardware configuration is 
given in figure This concept, designated Configuration 1, involves 
three separate digital computers: the main frame and two satellites, 

a control satellite, and a job -shop satellite. 

Control satellite . - The control satellite, in this configuration, 
is largely independent of the other computers. It contains an inde- 
pendent bank of auxiliary storage, together with an array of peripheral 
equipment. The minimum required peripheral equipment involves a card 
reader, a high-speed line printer, one on-line, and one off-line high- 
re,;: elution plotter . Flight data would be transmitted from the data 
reduction source to the auxiliary storage of the control satellite for 
subsequent editing and verification (utilizing the satellite and its 
peripheral display equipment). Following substantiation of the real- 
time data, the main frame would be interrupted, supplied with edited 
data, and directed to perform the REALBEPP analysis* REALBEPP output 
would be transmitted directly to the control satellite for peripheral 
processing. 


Job - shop satellite , - The job -shop satellite would be the standard 
type peripheral processor necessary to promote the off-line utilization 
of the main frame computer. The size and speed of this machine would 
depend upon the type of job-shop data processing it would be required 
to perform, 

Advantages of Configuration 1 ,- The primary advantage of Configu- 
ration I is facility of software development. This would only involve 
modifications to existing executive programs. Main frame interruption 
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could be accomplished easily with a minimum of overlap between the two 
computers. Peripheral, equipment would be completely segregated. Rapid 
development would be possible because of system simplicity. The link 
between installations would only involve a telephone line. 

Disadvantages of Configuration l .~ The primary disadvantage is 
hardware expense. Because two complete computer Installations would be 
involved with three computers and segregated peripheral gear, hardware 
expense appears to be larger than that of the other configurations. 

Analysis simulation in this case would necessarily involve both 
installations, similar to actual flight analysis. 


Configuration 2 

The minimum hardware outlay, Configuration 2, is illustrated in 
figure 4 . A single multi-purpose satellite computer is involved with 
the main frame in this configuration. The satellite performs all of the 
flight analysis functions plus the job-shop peripheral processing func- 
tions. The satellite would possess two different console units. The 
remote unit would be located in the MCC with all of the peripheral gear 
necessary for flight analysis. This console would be used both for simu- 
lation and flight analysis. The adjacent console would be implemented 
for job -shop and Imulation uses. 

Advantages of Configuration 2 .- Configuration 2 is attractive be- 
cause hardware expense is minimized, and the most efficient hardware 
utilization would ‘be realized. The equipment required in the propulsion 
support area of MCC would also be minimized, since computation, storage, 
and control modules of the satellite would be located in the Propulsion 
Building. Simulations would not require the MCC equipment, but could be 
conducted independent of MCC. 

Disadvantages of Configuration 2 .- Complexity of software would be 
the principal disadvantage of Configuration 2. The satellite’s executive 
program would necessarily be unique, because it would be required to do 
several different jobs (some more-or-less simultaneously). Some time- 
sharing features would probably be necessary for efficiency. Software 
development would be much more time consuming than that of Configura- 
tion 1. Special peripheral, hardware would probably be required also. 
Special coaxial cable would be necessary for the connection of the satel- 
lite and its remote equipment. 


6 


Configuration 3 

An effective compromise of Configurations 1 and 2 is realized in 
Configuration J>. The remote satellite console idea is retained. How- 
ever, the job-shop processing role is relegated to an independent satel- 
lite in this case. The control satellite is therefore used only for 
flight analysis functions. 

Advantages of Configuration 3 *- Similar to Configuration 1, the 
software development would be relatively simple. It could be accom- J 

pllshed by modifying existing software. Rapid development would be pos- 
sible because of system simplicity, Similar to Configuration 2, the 
peripheral equipment required in the MCC would be minimized, and simula- 
tions would not necessarily involve MCC. 

Disadvantages of Configuration 3 ,- Hardware cost is again the main 
disadvantage to this configuration, In addition, coaxial cables would 
be. required for connecting the remote console and its associated equip- 
ment to the control satellite, 


Discussion and Recommendations 

Configuration 3 represents the most success-oriented and at the 
same time the most practical configuration, Although Configuration 2 
represents slightly less hardware expense, it is believed that the soft- 
ware development for such a configuration could not be developed and 
verified in time to be effective for flight analysts of the block I mis- 
sions, The software development for Configuration 3, however, could be 
completed in approximately 2 months by the computer manufacturer. 

Simulation could be conducted from either building without dis- 
turbing the job-shop operation (except for actual machine interruption). 
Job- shop operators and flight analysis operators would be in different 
groups. 


SOFTWARE REQUIREMENTS 


Interrupt -Load-Re store Feature 

The job- shop operation of the flight analysis computers would be 
conducted in accordance with standard MSC practice. To perform flight 
analysis or flight simulation without disturbing job- shop operation, an 
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interrupt-load-restore feature could be utilized. The functions of this 
feature are*. 

a. To interrupt the main frame operation, 

b. To transfer the operating program, its data, and all of the 
machine registers to auxiliary storage, 

c. To load and execute the flight analysis programs, 

d. To transmit flight analysis output data to auxiliary storage 
or to the control satellite, and 

e. To restore the job-shop program to execution (at the point of 
interruption) upon completion of the flight analysis execution. 

The interrupt-load-restore feature -would be a part of the main frame 
software. The special mode would be triggered by an instruction from the 
control satellite. All subsequent operation of the main frame would be 
independent of the satellite except for the possibility of output trans- 
mission. 

When in the flight analysis operation mode, the software must be 
capable of protecting the peripheral equipment that was used in the job- 
shop mode. This is best accomplished by segregating the peripheral 
hardware and using two different executive programs (monitors). An ex- 
planation of how this might be accomplished is given below. 

Figure 6 is an expansion of Configuration 3 which illustrates the 
use of segregated peripheral equipment. The auxiliary storage is pre- 
sented as two banks of magnetic tape units, bank A for job-shop proces- 
sing and bank B for flight analysis processing. Bank A would be 
referenced exclusively by the job-shop monitor and the job-shop satel- 
lite, while bank B would be referenced exclusively by the flight analysis 
monitor and the control satellite. 

Job - shop monitor . - The main frame executive program for job -shop 
operation, Monitor A, would be a standard software package for the par- 
ticular computer involved. Under normal operation, Monitor A would 
recognize the existence of only the tape units in bank A. A special 
direct interrupt instruction from the control satellite would cause 
Monitor A to dump core memory and all machine registers onto one of the 
bank A units (specially reserved for this purpose). Monitor A would 
then read in the flight analysis monitor (Monitor B) from a special 
bank B unit. 
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Flight analysis monitor ." Monitor B, upon loading, would gain con- 
trol of the main frame and would proceed to dump Monitor A onto the 
specially reserved hank A tape, The flight analysis programs would he 
subsequently loaded and executed. All input/output processing would in- 
volve either the control satellite or the tape units in hank A. Upon 
completion of bhe flight analysis tasks, Monitor A would he loaded from 
the special hank A tape unit. Monitor A would then reload the inter- 
rupted program and return control to it at the Interruption point. 

Multiple day program usage ,- Several mission simulator programs a 

(thermal analysers, et cetera) in current usage require more than 
2k hours running time for simulation of spacecraft missions. For main- 
tenance reasons, computers cannot be operated continuously for such ex- 
tended periods, and special provisions for piecewise execution must be 
provided in each program. This would not he necessary if the interrupt - 
load-restore feature were available, since piecewise operation could 
then he implemented through monitor control. 


Special Language Compilers 

Expanded hardware utility .- The growth of problem oriented languages 
(Fortran, Algol, et cetera) has greatly expanded computer utility for 
scientific data processing. Such source languages are designed to eval- 
uate explicit algebraic expressions in a systematic manner, and are 
therefore quite useful in the numerical solution of engineering problems. 
However, most of these languages are sorely inadequate for input/output 
and list processing. Because of this, most large scientific programs 
must he supplemented by subroutines that are written in machine oriented 
language (assembly language). This is especially true when the program 
utilizes experimental test data which must be edited and filtered (and 
sometimes recalibrated) . 

For flight analysis computing, a source (problem-oriented) language 
is desired which is suitable for both test data processing and scientific 
computing. Source languages such as Fortran and Algol can be suffi- 
ciently extended if mixing of machine assembly code is allowed in each 
program. This characteristic could be easily included in most currently 
used compilers. In addition to, or in place of, imbedded machine code, 
the capability for generating and calling macro routines from the source 
language is a highly desirable attribute. Such an attribute would pro- 
vide the source-language programer with complete machine utilization 
capability. 

Formula manipulation capability .- One of the newest and most prom- 
ising developments in problem-oriented language capability is formula 
manipulation . Heretofore, scientific data processing has been limited 
to the use of numerical methods. Many engineers have either never 
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learned, or have had to ignore, analytic and theoretical approaches to 
problems because they have been forced to utilize numerical techniques 
exclusively. 

The ability of a digital computer to manipulate mathematical for- 
mulas serves to reactivate all of the powerful classical methods of 
mathematical physics. In existence now are languages which facilitate 
formula simplification, expansion, and factoring, as well as analytical 
differentiation and integration. Programs written in such languages are 
capable of power series and function series (Fourier, Bessel, et cetera) 
approximation and the implementation of analytical transformations 
(laPlace, Fourier). 

FORMAC (ref. 2), IBM's contribution, is an extension of FORTRAN 
which provides it with the ability to perform a certain amount of sym- 
bolic computation. Like FORTRAN, it is somewhat limited in scope and 
flexibility. 

A more general and flexible language, Formula Algol (ref. 3)> has 
been developed at Carnegie Institute of Technology. This language is an 
extension of Algol 60, which facilitates list processing and pattern 
recognition, as well as formula manipulation. 

A language of similar capability, MATHLAB, is being developed at 
MIT and MITRE corporation (ref, 4), MATHLAB is designed for use in an 
integrated man/machine arrangement with the aim of providing instanta- 
neous formulation/solution capability to the scientist. 

In the propulsion flight analysis effort, extensive use of the 
formula-manipulation capability is envisioned. The ability to modify 
formulas at execution time relieves the propulsion- system model designer, 
who is constantly harassed by hardware design changes. Many existing 
simulation programs become obsolete because modifications cannot keep 
pace with changes in propulsion hardware. Analytical formulation of the 
partial derivatives required in the BEPP analysis comprises a large part 
of the program development work. The ability to change the partial de- 
rivatives without program modification provides complete flexibility in 
the selection of primary and secondary parameters for the BEPP process. 
With formula manipulation, propulsion simulation models could be uti- 
lized as input data rather than as built-in portions of the BEPP programs. 

With complex hardware installations, such as the one proposed, pro- 
graming flexibility is mandatory for efficient machine utilization. Such 
flexibility is adequately provided by the use of language compilers which 
possess the foregoing characteristics. 
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Figure 2.- Special purpose computer configuration. 
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Figure 6.- Configuration 3 with hardware segregation. 


































